-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a GitHub action for periodically running vale and storing the results #281
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of things to think about:
This will change fairly significantly as we re-assess severity levels.
How useful is running periodic checks in comparison to running on PR actions? We could just implement checks as non-blocking, as we will eventually want to turn that switch on, and it would save us some work further down the line.
I don't think this will provide useful data until Vale is in a more stable state - and we'll continue to iterate next cycle to refine Vale's output.
Co-authored-by: Michael Park <[email protected]>
@SecondSkoll Severity levels? (DOCPR-776 seems to be the wrong one) @evilnick was there a specific reason for wanting periodic vale checks instead of running them as non-blocking PR actions? Yes, we could wait for vale to become more stable before including it in our workflows. |
Quite right, wrong issue. Yes, changing the severity levels will change the output, also any refinements we make after testing. Presumably next cycle will involve some level of optimisation and reworking of rules - otherwise Vale is going to cause a lot of noise. |
I am going to be tweaking the default Vale config this pulse so we can push a v1.0 out. So for example, maybe on a PR the pa11y text complains about something. You may chose to see it as junk, or merge anyhow if it is non blocking. Those tests don't tell us anything about the docs that are published. a recurring task which logs a dozen a11y failures, or broken links is more useful |
uses: actions/upload-artifact@v4 | ||
with: | ||
name: vale-results | ||
path: vale_results_clean.txt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggest we put these in the /metrics directory the other testing PR adds
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🍰 but see comment
I'm going to close this due to our discussion from 2024/09/26. |
can we modify this action so it just runs and doesn't store output ( i mean, it can output to the console and we can than see it in the run logs anyhow). |
All changes from main have been merged in to the use-canonical-sphinx-extension branch. It would be great to submit a PR against that branch instead as it's about to become the main branch. |
Sure, I can submit a PR for it in that branch. |
Current automated documentation checks do not include style checks. To include style checks using vale, this PR adds a GitHub action that runs once a week and stores the results in a GitHub artifact that can be downloaded.
Addresses DOCPR-876